home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / mmdf / mmdf43_docs / review / p7 < prev    next >
Encoding:
Text File  |  1986-02-01  |  3.6 KB  |  83 lines
  1. .SH
  2. The List Channel
  3. .PP
  4. The list channel was developed as the result of BRL's experience
  5. in managing \fBlarge\fR Internet mailing lists.
  6. Two major problems were discovered with dealing with mailing lists
  7. in MMDFI.  First, since \fBsubmit\fR always verifies all known addresses
  8. for a message at submission time, if you were on the machine with
  9. a large list and submitted mail to the list you would have to wait
  10. for every address on that list to be verified.
  11. On a busy machine
  12. with a list of hundreds of addresses, this could take
  13. five or ten minutes.
  14. Annoying as this may be for people,
  15. the situation was worse for mail submitted over communications
  16. channels like TCP/IP.  The remote end would continually time out
  17. before the message had been completely verified so the message
  18. could never be sent.
  19. .PP
  20. The second problem with large lists was that there were always
  21. rejected mail notices going back to those
  22. least able to do anything about the mail problem, the original
  23. sender of the message.  What was really desired was a method to
  24. try to have returned mail go to the list maintainer instead
  25. of the message's original sender.
  26. .PP
  27. The solution to both of the problems is embodied in the list channel.
  28. This is a channel with an incestuous relationship
  29. to \fBsubmit\fR, \fBdeliver\fR,
  30. and the alias file.
  31. Use of the list channel is best described in parallel with the
  32. special entries for the list channel in the alias file.
  33. If we were maintaining a large list called ``biglist'', the following
  34. entries would be in the alias file:
  35. .nf
  36. .ta 2.6i
  37. .sp .5
  38. .in +.6i
  39. biglist:    biglist-outbound@list-processor
  40. .br
  41. biglist-outbound:    </usr/mmdf/lists/biglist-file
  42. .br
  43. biglist-request:    maintainer
  44. .in -.6i
  45. .fi
  46. .sp .5
  47. The pseudo-host ``list-processor'' has its own domain table and its
  48. own host table but represents no actual host.  If someone submits
  49. mail to biglist, \fBsubmit\fR will find the alias entry and
  50. upon finding that it's
  51. not a local address, will queue it to the host ``list-processor'',
  52. so verification is complete after only one lookup.
  53. Unknown to
  54. \fBdeliver\fR, the list channel simply calls \fBsubmit\fR and feeds it the
  55. aliased addresses, ``biglist-outbound''.
  56. This time the actual verification is done on the contents of
  57. the address list ``biglist-file''.  Since the list channel is processed
  58. by a background daemon, no one is forced to wait through the
  59. verification process except the background daemon itself, which doesn't care
  60. how long it takes so long as it completes.
  61. .PP
  62. The list channel also performs another function to try to
  63. eliminate the problem of failed mail messages.
  64. For each address given to it, (normally just one), the list channel
  65. sees if there is a matching ``\fIlistname\fR-request'' entry in the alias
  66. table.  It knows enough to try stripping any ``\-outbound''s from
  67. the name first though.  If a ``\-request'' entry is found, then
  68. that address is substituted instead of the original return
  69. address.  The message text is \fInot\fR altered, but the new return address
  70. is recorded for use when resending the message.
  71. The new return address
  72. is supplied in SMTP ``MAIL FROM:<\fIaddress\fR>'' commands and any other
  73. situations where the return address is directly specifiable.
  74. .PP
  75. The changing of the return address is useful only if mail is rejected
  76. when submitted to the foreign host or if that host is smart enough to keep
  77. the return address information around.  Many hosts do not maintain this
  78. information,
  79. and many of the same hosts are also problematic in that they
  80. will completely accept a message containing total garbage and
  81. decide to tell you about it later.  This is precisely what MMDF tries
  82. to avoid by submission-time verification.
  83.